Week 7, Day 2 — Defender for Endpoint

Day 1 review & the device-layer gap

• Ask: "Safe Attachments quarantines a malicious PDF before it reaches the inbox — great. But what if malware is already on the device, installed via USB six months ago, sitting dormant? What does Defender for M365 do about that?" — answer: nothing. Defender for M365 protects cloud workloads. It has no visibility into what's running on the device. That's Defender for Endpoint's job.
• Ask: "WIN-CLIENT-01 is enrolled in Intune, has the Security Baseline, and has Defender Antivirus running. Is that the same as Defender for Endpoint?" — no. Windows Defender Antivirus (the built-in AV) detects known malware signatures. Defender for Endpoint is an EDR — Endpoint Detection and Response — that does behavioural monitoring, threat hunting, vulnerability assessment, and automated investigation. They coexist; Endpoint uses the AV as one of its sensors.
• Frame the day: today's lab connects Week 6 (Intune device management) with Week 7 (threat protection). Onboarding via Intune is a single config profile push — the same mechanism used for KFM and Update rings. Once onboarded, WIN-CLIENT-01 gets a sensor that reports to the Defender portal. We run a test detection to see what an alert looks like. Then we wire Defender's risk level back into the Intune compliance policy — closing the loop: a device with active malware becomes non-compliant and loses M365 access automatically.

Defender for Endpoint — architecture, onboarding, and EDR concepts

Defender for Endpoint (MDE) is an enterprise EDR platform. Unlike antivirus which looks for known signatures, EDR watches device behaviour continuously and alerts on suspicious patterns — even if the specific malware has never been seen before.

The onboarding flow — three options, one recommended path for Intune environments

• Why Intune onboarding is the right path for this course — WIN-CLIENT-01 is already Intune-managed from Week 6. An Intune Endpoint Detection and Response configuration profile pushes the onboarding package (a blob of tenant-specific settings) to the device silently. No manual steps on the client. This is how production deployments work at scale. The local script option (Option B) is useful for manual testing and is covered as a fallback if the profile method hits issues.
• First-time activation of Defender for Endpoint — unlike Defender for M365 which activates automatically when the licence is assigned, Defender for Endpoint requires the service to be explicitly turned on in the Defender portal settings. Navigate to security.microsoft.com → Settings → Endpoints → Onboarding. If you see a "Set up Microsoft Defender for Endpoint" page, the service needs to be initialised — this is a one-time action per tenant.
• What the EDR sensor does — once onboarded, the device reports a continuous stream of telemetry to Defender for Endpoint: process creations, network connections, file system changes, registry modifications, logon events. Defender analyses this stream using behavioural detection rules and machine learning. When it detects something suspicious, it generates an alert. Multiple related alerts become an incident. The security team investigates incidents, not individual alerts.
• Device risk levels — Defender for Endpoint assigns each device a risk level: None, Informational, Low, Medium, High. This risk level is exposed to Intune as a compliance signal. You can configure the Intune compliance policy to require a maximum Defender risk level — a device assessed as High risk by Defender is marked non-compliant in Intune and blocked from M365 by CA001. This is the full loop: threat intelligence → device compliance → access control.
• The EICAR test file — a harmless 68-byte text string standardised by the anti-malware industry as a safe way to test AV/EDR detection without using real malware. Any security product that detects malware should detect EICAR. Downloading and saving the EICAR test file to WIN-CLIENT-01 will trigger a Defender for Endpoint alert — generating a real alert in the Defender portal without any actual risk.

Lab 7-B: Onboarding WIN-CLIENT-01 to Defender for Endpoint, detection test, and risk-level compliance wiring

Students activate Defender for Endpoint, onboard WIN-CLIENT-01 via an Intune configuration profile (with local script as fallback), verify the device appears in the Defender portal, run an EICAR detection test, explore the resulting alert, and update the Intune compliance policy to enforce a maximum Defender risk level.

• Step 1 — Activate Defender for Endpoint and check initial state (8 min)
  Navigate to security.microsoft.com → Settings → Endpoints → Onboarding.
  Two possible states:
  · If you see a device inventory or onboarding options — the service is already active. Note the operating system dropdown (Windows 10 and 11) and the three onboarding method options. Proceed to Step 2.
  · If you see a "Set up Microsoft Defender for Endpoint" page — click through the setup wizard to initialise the service. This is a one-time tenant-level activation. It takes 1–5 minutes. Refresh and return to Settings → Endpoints → Onboarding when complete.
  
  Record which state your tenant was in.
• Step 2 — Configure Defender for Endpoint via Intune (Recommended path) (15 min)
  Navigate to intune.microsoft.com → Endpoint security → Endpoint detection and response → + Create policy.
  · Platform: Windows 10, Windows 11, and Windows Server
  · Profile: Endpoint detection and response
  · Name: LL — MDE Onboarding
  
  Under Configuration settings:
  · Microsoft Defender for Endpoint client configuration package type: Auto from connector — this automatically uses the onboarding blob from your tenant's MDE service, no manual download required.
  · Sample sharing: All
  · Expedite telemetry reporting frequency: Enable
  
  Assign to: SG — All Windows Devices. Save.
  
  On WIN-CLIENT-01, trigger a sync: Settings → Access work or school → Info → Sync. The onboarding profile will be applied in the background.
• Step 2 (Alternative) — Onboard via local script if Intune profile method fails (10 min)
  If the Intune profile method doesn't onboard the device within 15 minutes, use the local script as a fallback:
  Navigate to security.microsoft.com → Settings → Endpoints → Onboarding.
  Deployment method: Local script. Download the WindowsDefenderATPOnboardingPackage.zip.
  Transfer to WIN-CLIENT-01. Extract and run WindowsDefenderATPLocalOnboardingScript.cmd as Administrator.
  Answer 'Y' when prompted. The script runs and returns "Onboarding succeeded."
• Step 3 — Verify WIN-CLIENT-01 appears in the Defender portal (10 min)
  Navigate to security.microsoft.com → Assets → Devices.
  WIN-CLIENT-01 should appear. Note: onboarding can take 5–30 minutes to fully register. If the device is not yet visible, proceed to Step 4 and return to verify.
  
  Once visible, click WIN-CLIENT-01 to open the device page. Record:
  · Risk level (will initially show None or Informational)
  · Exposure level
  · Onboarding status
  · Last seen time
  · Active alerts count
  · Device health status
• Step 4 — Run an EICAR detection test on WIN-CLIENT-01 (10 min)
  On WIN-CLIENT-01, open a browser and navigate to:
  https://www.eicar.org/download-anti-malware-testfile/
  Download the eicar.com test file (the standard test file, not the zip versions first).
  
  Windows Defender Antivirus should detect and remove it immediately — you will see a Windows Security notification. This is expected and confirms AV is active.
  
  The detection generates telemetry that Defender for Endpoint sends to the Defender portal. Return to security.microsoft.com → Incidents & alerts → Alerts. Within 5–15 minutes, a new alert should appear for WIN-CLIENT-01 related to the EICAR test file.
  
  Click the alert to explore its details.
• Step 5 — Explore the alert and incident (10 min)
  In the alert detail view, explore:
  · Alert title and severity
  · Detection source (Windows Defender Antivirus / EDR / etc.)
  · Affected device (WIN-CLIENT-01)
  · Attack story — the graphical process tree showing what happened (which process downloaded the file, where it was saved)
  · Recommended actions
  
  Navigate to Incidents & alerts → Incidents. Check if the alert has been grouped into an incident (multiple related alerts form an incident automatically).
  
  Navigate back to Assets → Devices → WIN-CLIENT-01. Note whether the Risk level has updated from the EICAR detection.
• Step 6 — Wire Defender risk level to Intune compliance (10 min)
  First, ensure the Defender for Endpoint — Intune connector is active:
  Navigate to intune.microsoft.com → Endpoint security → Microsoft Defender for Endpoint. Confirm the connector status shows Enabled. If not, click Open the Microsoft Defender for Endpoint admin console and enable the connector from the Defender portal settings.
  
  Now update the compliance policy:
  Navigate to Devices → Compliance → LL — Windows Baseline Compliance → Edit.
  Scroll to the Microsoft Defender for Endpoint section. Set:
  · Require the device to be at or under the machine risk score: Medium
  
  Save. This means any Windows device with a Defender risk level of High will be marked non-compliant by Intune and blocked from M365 by CA001.

⭐ Bonus: Vulnerability management and live response

Reflection & preview

• Ask: "WIN-CLIENT-01 gets infected with ransomware at 2pm. Defender for Endpoint detects it at 2:05pm and marks the device as High risk. Intune checks in at 3pm and marks it non-compliant. CA001 blocks M365 access at 3:05pm when the user next tries to sign in. The ransomware has been encrypting files since 2pm. What is the gap, and what would reduce it?" — Continuous Access Evaluation + shorter Intune check-in interval + automated device isolation from the Defender portal
• Ask: "LINUX-01 is enrolled in Intune. Can you onboard it to Defender for Endpoint the same way?" — yes, Defender for Endpoint supports Linux (deb package, similar to the Intune Linux agent). The same risk-level compliance wiring works cross-platform.
• Preview Day 3: Secure Score — a single number that summarises the security posture of the entire tenant. Students will see which of their Week 1–7 configurations contributed positively, which gaps remain, and then run an attack simulation to see how users respond to a credential-harvest phishing email.